1. Field of the Invention
The invention relates to mobile communication systems. Particularly, the invention relates to the transfer of packet header and data compression parameters in a mobile communication system.
2. Description of the Related Art
A disadvantage associated with wireless data transmission is that the data transfer rate is limited compared to wire-line data transmission. Especially, the data transfer rate is limited in cellular mobile communication systems where a given frequency band must be shared by a number of simultaneous users. When transferring packet data in a cellular mobile communication system, the data transfer rate made available for application layer data transmission is further reduced due to frame and packet headers. For example, when the Transmission Control Protocol (TCP) is carried over the Internet Protocol (IP) version 4, the total header size is 40 bytes of which TCP layer headers take 20 bytes and IP layer headers 20 bytes. In IPv6 the IP layer header size is 40 bytes. The problem is made worse in the cases where IP-in-IP tunneling is used, for example, in association with the Mobile IP.
In order to alleviate the aforementioned problems associated with wireless and in general slow links payload data and header compression schemes have been introduced. Examples of such header compression schemes are Van Jacobson header compression defined in the Internet Engineering Task Force (IETF) Request For Comments (RFC 1144) and Degermark header compression defined in the IETF RFC 2507. An example of a payload data compression scheme is V.42bis by International Telecommunications Union (ITU-T).
Generally, header compressions rely on the fact that a large part of the headers contain information, which remains constant during the course of a typical TCP/IP connection. Similarly, when Universal Datagram Protocol (UDP) is carried over IP, a significant part of the packet headers remain constant in any given flow, which carries, for example, streaming multimedia. An IP header comprises a number of fields. As a sequence of IP packets is transmitted, there is no need to repeatedly transmit the fields that are not changed between subsequent packets. Those fields that usually change with small or predictable values, for example, TCP sequence numbers in TCP headers, may be encoded incrementally so that the number of bits needed for transmitting the value of those fields decreases significantly. Only those fields that change often and randomly, for example, checksums or authentication data, need to be transmitted in entirety in each header. In header compression is sent occasionally a packet with a full header, which establishes a context. Thereupon, in subsequent packets compressed headers refer to the established context and may contain incremental changes to the context. In order for the header compression to work, it is necessary that a sender and a receive maintain the same context. A number of different contexts may be maintained in the sender and the receiver side to support different packet streams carried over same link, that is, for example, TCP/IP connections or UDP packet flows.
Payload data compression relies, on the other hand, upon the redundancy of data to be carried in packet payload. For example, there may be repeating strings in packets. The compression is achieved by maintaining by at the sender and at the receiver side code dictionaries than comprise information on strings comprised in the uncompressed data. The code dictionaries enable the sender to refer to codes instead of entire strings while the transmission occurs in the compressed mode. The V.42bis compression relies on the Lempel-Ziv-Welch algorithm. More information on the Lempel-Ziv-Welch algorithm can be found, for example, in U.S. Pat. Nos. 4,955,066, 4,701,745 and 5,016,009.
In association with mobile communication systems the use of header compression and payload data compression has been standardized, for example, in the General Packet Radio System (GPRS). Header compression and payload data compression is used between a mobile station and a Serving GPRS Support Node (SGSN) in order to decrease the amount of data to be transmitted over the air interface between the mobile station and a base transceiver station.
Reference is now made to FIG. 1, which is a block diagram illustrating the architecture and the protocol stacks in a GPRS system in association with the GSM Edge Radio Access Network (GERAN). The GPRS system is specified, for example, in the 3G Partnership Project (3GPP) specification 23.060. The protocol stacks are illustrated from the user plane point of view. In FIG. 1 there is a Gateway GPRS Support Node (GGSN) 106. GGSN 106 is connected to an external network (not shown) via a Gi-interface. The external network may be an arbitrary IP network, for example, the Internet or an intranet. In FIG. 1 there is also a Serving GPRS Support Node (SGSN) 104. GGSN 106 communicates with SGSN 104, which routes packets to and from Mobile Station (MS) 100 via a Base Station Subsystem (BSS). SGSN 104 takes care of the mobility related tasks such as the maintaining of mobile station 100 location information, network registrations, routing area and location updating, Packet Data Context (PDP) activation and deactivation, handovers and the paging of mobile station 100. Part of the above mentioned tasks are naturally done in other network elements with which SGSN 104 is communicating. The GGSN is responsible for routing and tunneling packets to and from a number of SGSN 104 and other SGSNs. The routing is based on SGSN address information maintained in a Packet Data Protocol (PDP) context held by GGSN 106. There is at least one PDP context for each network address activated for MS 100, for example, an IP address or an X.25 address or a PPP link.
In FIG. 1, the uppermost protocol layer in MS 100 is the application layer (APPL). The application layer may be any protocol, for example, a protocol from the Wireless Application Protocol (WAP) standard or the Transmission Control Protocol (TCP) or the Universal Datagram Protocol (UDP). Over the TCP/IP may be carried, for example, Hypertext Transfer Protocol (HTTP). The application layer communication is exchanged with a peer host, which may be located behind the Gi-interface, for example, in the Internet. Below the application layer there is the IP layer or alternatively X.25 layer, which in GPRS is supported by both MS 100 and GGSN 106. The IP address for packets addressed to MS 100 points to GGSN 106. An IP packet 114 is conveyed to MS 100 using GPRS user plane protocols below the IP layer. Between GGSN 106 and SGSN 104 IP packet 114 is conveyed using the GPRS Tunneling Protocol (GTP). A GTP packet carried further over UDP/IP.
In SGSN 104 IP packet 114 data is routed based on MS 100 location information and passed to Sub-Network Dependent Convergence Protocol (SNDCP) layer. SNDCP is specified in the 3GPP specification 44.065. SNDCP layer maps network-level characteristics onto the characteristics of the underlying network. For example, SNDCP takes care of the transmission and reception of Network layer Protocol Data Units (N-PDU) carrying IP packets. For example, IP packet 114 is carried in N-PDU 112. SNDCP multiplexes several packet data protocol packets for the same MS. It segments IP packet 114 to LLC frames, for example, LLC frame 110. It also reassembles packets from LLC frames. Header compression and data compression is also performed at SNDCP layer. The header compression scheme mentioned in the 3GPP specification 23.060 includes TCP/IP header compression. V.42bis is mentioned as a method for data compression. At the SNDCP layer there are a number of compression entities (not shown) each of which have associated with them an algorithm and the entity specific parameters. Each SNDCP entity, which supports protocol control information compression, is able to negotiate at least one protocol control information compression entity using XID parameter negotiation as specified in the 3GPP specification 44.064. The initiating SNDCP entity defines a set of requested compression entities, together with the algorithm and parameters for each compression entity. The set of compression entities and their algorithms and parameters are transmitted to the peer SNDCP entity. The peer SNDCP entity responds with the set of negotiated compression entities and their algorithms and parameters. The peer SNDCP entity selects the proposed parameter values or other appropriate values for the negotiated compression entities. The information on the set of compression entities used and their algorithms and parameters is referred to hereinafter as the SNDCP compression parameters. Other compression information held at the SNDCP layer comprise, for example, at least one header compression context and at least one code dictionary. SNDCP performs parameter negotiation between MS 100 and SGSN 104. SNDCP also buffers N-PDUs in the case of acknowledged mode services.
The Logical Link Control (LLC) layer provides a highly reliable link between MS 100 and SGSN 104. The LLC is specified in 3GPP specifications 44.064 and 04.64. The LLC is independent of the underlying radio protocols and hides the BSS and radio interface related tasks from the LLC layer users. LLC supports variable-length information frames. LLC supports both acknowledged and unacknowledged data transfers, that is, acknowledged and unacknowledged modes of operation. LLC provides services typical to a link layer comprising parameter negotiation, flow control in the Asynchronous Balanced Mode (ABM), sequence control to maintain the ordering of LLC-frames, expedited delivery for high-priority data, error detection, error recovery and indication. LLC performs data confidentiality by means of the ciphering of LLC-frame contents. LLC also supports user identity confidentiality by means of the use of Temporary Logical Link Identity (TLLI) instead of International Mobile Subscriber Identity (IMSI). A Service Access Point Identifier (SAPI) identifies a point, at which LLC services are provided by a Logical Link Entity (LLE), in other words an LLC entity, to a layer-3 entity. Consequently, SAPI identifies an LLE that should process an LLC frame and also a layer-3 entity that is to receive information carried by the LLC frame. The layer-3 entity is, for example, an SNDCP entity.
The relay layer relays LLC PDUs between the Um and Gb interfaces in the BSS. The Base Station System GPRS Protocol (BSSGP) layer specified in 3GPP specification 08.18 conveys routing and QoS-related information between the BSS and the SGSN. For example, it carries radio resource related requests from the SGSN to the BSS 102. It also carries LLC frames between the BSS and the SGSN. In addition to LLC frames it also carries signaling PDUs associated with GRPS mobility management. The Network Service (NS) layer transports BSSGP PDUs between BSS and SGSN. NS may be based on Frame Relay (FR). The RLC sub-layer within the RLC/MAC layer provides a radio technology dependent reliable link between MS 100 and BSS 102. The MAC sub-layer performs the requesting and reservation of radio resources and maps LLC frames onto the GSM physical channels. The task of the MAC layer is to ensure efficient sharing of common radio resources by several mobile stations. The RLC/MAC layer is defined in the 3GPP specification GSM 04.60.
Reference is now made to FIG. 2, which is a block diagram illustrating packet transmission before and after a routing area update in a prior art GPRS network. In FIG. 2 there is an MS 100, Base Transceiver Stations (BTS) 224-228 and Base Controller Stations (BSC) 210-214 in BSS 216. There is a GGSN 200, which is connected to IP network 201. From IP network 201 is received a downlink packet stream 240. Initially, downlink packet flow 240 is tunneled from GGSN 200 to SGSN 202 as packet stream 241. Initially, SGSN 202 routes packets from packet stream 241 to MS 100 via BSC 212 and BTS 222 as packet stream 242. Packet stream 242 is carried from an SNDCP entity 252 in SGSN 202 to SNDCP entity 230 in MS 100 using an LLC connection serving both SNDCP entities. BSC 212 and BTS 222 are referred to as source BSS 262. MS 100 communicates with BSC 212 via BTS 222. In routing area update related signaling SGSN 202 communicates with MS 100 via BSC 212 and a BTS 222 within BSS 262.
When MS 100 detects that a new cell has better radio quality, it must start camping on the new cell, which is served by BTS 224. The new cell is in the area of a new SGSN 204. After the handover, packet stream 240 should be routed to MS 100 from GGSN 200 via SGSN 204, BSC 214 and BTS 224. BSC 214 and BTS 224 are also referred to as a target BSS 264. While the PDP contexts have not yet been updated in GGSN 200, SGSN 202 must forward any unacknowledged packets to SGSN 204. The packets are sent from SGSN 202 as packet stream 243. After GGSN 200 has received a PDP context update request and processed it, it may start sending packets from packet stream 240 directly to SGSN 204 as packet stream 244. SGSN 204 sends packets from packet streams 243 and 244 to MS 100 as packet stream 245. Packet stream 245 is carried from an SNDCP entity 254 in SGSN 204 to SNDCP entity 230 in MS 100 using an LLC connection serving both SNDCP entities. Before packets may be sent from SGSN 204 to MS 100 after the detection of a routing area update, an XID reset procedure must be performed between SNDCP entities 254 and 230. Otherwise, the LLC parameters will not match in the MS 100 and SGSN 254 and all LLC frames will be rejected.
Reference is now made to FIG. 3, which is a signaling diagram depicting routing area update signaling in a prior art GPRS network such as illustrated in FIG. 2. At time t1 an MS 100 detects an event that indicates that it must start using a new cell (not shown). The new cell is within a new routing area, which is controlled by a new SGSN 204. MS 100 sends a Routing Area Update Request message to SGSN 204 as illustrated with arrow 301. The message is sent via a target BSS 264, which controls the new cell. SGSN 204 sends an SGSN Context Request message illustrated with arrow 302 to an old SGSN 202 to get the mobility management and PDP contexts for MS 100. The SGSN Context Request message comprises, for example, an old routing area identifier, a Temporary Logical Link Identity (TLLI) and the new SGSN address. SGSN 202 responds with message SGSN Context Response illustrated with arrow 303. The SGSN Context Response message provides the mobility management context and at least one PDP context associated with MS 100. After receiving the SGSN Content response message SGSN 204 may initiate an XID reset procedure. XID-reset procedure comprises that an SNDCP entity 254 in SGSN 204 requests an LLC-entity in SGSN 204 to send an XID command message to MS 100 as illustrated with arrow 304. In the case of XID reset, the XID Command message includes a Reset parameter, which tells the peer LLC entity to reset the LLC parameters. MS 100 acknowledges the XID Command with the XID Response message as illustrated with arrow 305.
As defined in 3GPP specification 44.064 several actions take place at the XID procedure if a Reset parameter is detected in an XIID Command message. All requests pending from layer 3 to the LLC entities in SGSN 204 and MS 100 are discarded without any further action. Any ongoing Asynchronous Balanced Mode (ABM) establishment, release and XID negotiation procedures are aborted, except the XID negotiation pertaining to a Reset parameter. The LLC layer parameters are set to the default values. Any Logical Layer Entities (LLE) in ABM state is changed to Asynchronous Disconnected Mode (ADM) state. Unconfirmed state variables V(U) and V(UR) are set to 0. Further, all Overflow Counters (OC) for unacknowledged information transfer are set to 0.
After having received the SGSN 204 address, SGSN 202 may start forwarding packets to it as illustrated with arrow 306. SGSN 204 must update PDP contexts in the GGSNs that have PDP contexts active for MS 100. The updating of PDP contexts specifies, for example, the new SGSN address for the GGSNs. SGSN 204 sends the Update PDP Context Request message to GGSN 200 and receives Update PDP Context Response message as acknowledgement, as illustrated with arrows 307 and 308, respectively. The routing area update is acknowledged with Routing Area Update Accept message sent by SGSN 204 to MS 100, which responds by sending Routing Area Update Complete message to SGSN 204, as illustrated with arrows 309 and 310.
The ABM release that is performed in association with the processing of XID Reset parameter specified in the XID Command message causes significant problems in prior art. After the XID reset the ABM mode must be re-established with Set Asynchronous Balanced Model (SABM) negotiation sent to MS 100. This is illustrated using arrow 310. The Unnumbered Acknowledgement (UA) response to the ABM mode re-establishment from MS 100 is illustrated with arrow 311.
However, without knowledge of the previously used SNDCP parameters there is no possibility to re-establish the ABM mode with the SNDCP parameters that were used by the old SGSN, namely SGSN 202, to communicate with MS 100. There are three problems related to this. Firstly, if SGSN 204 does not propose any compression entities, in other words, header or data compression entities, in the SNDCP compression parameters negotiated after XID reset procedure, there is no guarantee that the MS 100 will stop using the previously used SNDCP compression parameters. Secondly, if SGSN 204 proposes any compression entities there is no guarantee that MS 100 is capable of changing them. Thirdly, if SGSN 204 in fact proposes a header compression entity, there remains the question as to whether RFC 1144 or RFC 2507 header compression should be used by default. Some mobile stations do not work properly in the first case and some do not work properly in the second and third cases.